home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1307.txt < prev    next >
Text File  |  1994-08-01  |  24KB  |  731 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           J. Young
  8. Request for Comments: 1307                                  A. Nicholson
  9.                                                      Cray Research, Inc.
  10.                                                               March 1992
  11.  
  12.  
  13.                Dynamically Switched Link Control Protocol
  14.  
  15. Status of this Memo
  16.  
  17.    This memo defines an Experimental Protocol for the Internet
  18.    community.  Discussion and suggestions for improvement are requested.
  19.    Please refer to the current edition of the "IAB Official Protocol
  20.    Standards" for the standardization state and status of this protocol.
  21.    Distribution of this memo is unlimited.
  22.  
  23. Abstract
  24.  
  25.    This memo describes an experimental protocol developed by a project
  26.    team at Cray Research, Inc., in implementing support for circuit-
  27.    switched T3 services.  The protocol is used for the control of
  28.    network connections external to a host, but known to the host.  It is
  29.    documented here for the benefit of others who may wish to perform
  30.    further research.
  31.  
  32.    While working with circuit-switched T3 networks, developers at Cray
  33.    Research, Inc., defined a model wherein a host would generate control
  34.    messages for a network switch.  This work is described in RFC 1306,
  35.    "Experiences Supporting By-Request Circuit-Switched T3 Networks".  In
  36.    order to simplify the model it was decided that the inconsistencies
  37.    of switch control should be hidden from the host generating the
  38.    control messages.  To that end, a protocol was defined and
  39.    implemented.  This RFC documents the Dynamically Switched Link
  40.    Control Protocol (DSLCP), which is used for creation and control of
  41.    downstream network links by a host.
  42.  
  43. 1.0  INTRODUCTION
  44.  
  45.    The Dynamically Switched Link Control Protocol (DSLCP) allows a host
  46.    with knowledge of a special downstream network link to issue messages
  47.    to control the status of that link.
  48.  
  49.    This document describes the functions of the DSLCP to control
  50.    external network connections.
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Young & Nicholson                                               [Page 1]
  59.  
  60. RFC 1307       Dynamically Switched Link Control Protocol     March 1992
  61.  
  62.  
  63. 1.1  Motivation
  64.  
  65.    Circuit Switched Networks are becoming available to the Internet
  66.    community.  These networks are made available by requesting a
  67.    connection through a switch.  Normally circuit switched network links
  68.    are disconnected, and their prohibitive cost suggests that it is very
  69.    costly to leave them connected at all times.
  70.  
  71.    Internet users and hosts wish to send data over a circuit switched
  72.    networks, but only connect the network links when a transport
  73.    connection is to be established.  While it would be possible to use
  74.    packet routers to identify the need for switching a connection on and
  75.    off, only the transport provider can positively identify the
  76.    beginning and end of a transport session.  There must be a mechanism
  77.    to activate and deactivate the link at the beginning and end of a
  78.    transport session.
  79.  
  80.    The DSLCP assumes that a transport provider has knowledge of a
  81.    downstream link which must be setup before data transfer may take
  82.    place.  However, the details of link setup may vary by the type of
  83.    link (circuit-switched or other), specific hardware, or
  84.    administrative differences.  The DSLCP hides these details from the
  85.    transport provider by offering a simple request/release model of link
  86.    preparation.  The model assumes an entity in control of the link
  87.    which handles the details of connection preparation while responding
  88.    to the DSLCP commands of the transport provider.  This entity is
  89.    called the link controller.
  90.  
  91.    The DSLCP allows internet hosts to dynamically change the fabric of
  92.    the internet by sending messages through the internet in advance of
  93.    data which is to travel across the newly created links.
  94.  
  95. 1.2  Scope
  96.  
  97.    DSLCP is intended to provide an interface between transport providers
  98.    and arbitrary network links requiring creation, control, setup, or
  99.    conditioning before data communications may take place.
  100.  
  101. 1.3  Interfaces
  102.  
  103.    There are no specific user level interfaces to DSLCP, although they
  104.    are not precluded.  Link control is a function of the network layer,
  105.    initiated by requests from the transport provider.
  106.  
  107.    A DSLCP transaction is defined as a transport provider communicating
  108.    with a link controller for the duration of transport session.  A
  109.    network path between the host providing transport services and the
  110.    link controller must exist in advance of the DSLCP transaction.
  111.  
  112.  
  113.  
  114. Young & Nicholson                                               [Page 2]
  115.  
  116. RFC 1307       Dynamically Switched Link Control Protocol     March 1992
  117.  
  118.  
  119.    Either party to an DSLCP transaction may asynchronously generate
  120.    messages.
  121.  
  122. 1.4  Operation
  123.  
  124.    The purpose of the DSLCP is to allow a transport provider to request
  125.    the setup of a downstream network link so that data transfer may take
  126.    place through that link.  DSLCP messages are assumed to be
  127.    communicated between the transport provider and the link controller
  128.    through a transport service, such as UDP or TCP, or through a network
  129.    service such as IP.
  130.  
  131.    DSLCP provides messages for link setup and teardown.  All the details
  132.    of link management are left to the link controller.  The transport
  133.    provider is interested only whether the link is ready to carry data.
  134.  
  135. 1.5  Transmission
  136.  
  137.    DSLCP messages are carried through the network in datagrams using
  138.    either IP or UDP.  DSLCP is designed to not require a reliable
  139.    transport protocol.
  140.  
  141. 2.0  DSLCP Architecture
  142.  
  143.    DSLCP is used in a host environment.  Normally, transport users on
  144.    the host will make requests of a transport provider to carry data to
  145.    other hosts.  Some of these requests may require the preparation of a
  146.    downstream network link.  The transport provider has knowledge of
  147.    these special network links, and issues a request to DSLCP that the
  148.    link be prepared to carry data.  This happens transparently to the
  149.    transport user.
  150.  
  151.    When a transport user requests transport services, the transport
  152.    provider will normally attempt to establish a connection.  In the
  153.    event the transport provider discovers that the connection requires
  154.    special link control, the transport provider will call upon DSLCP to
  155.    send a link setup message to the link controller.  The transport
  156.    provider does not attempt to use the connection until DSLCP informs
  157.    the transport provider that the link is setup or that the setup
  158.    attempt failed.  If the setup failed, then the transport provider is
  159.    free to attempt to find another way to create a connection.
  160.  
  161.    When the transport user is finished using the services, then the
  162.    transport provider will call DSLCP to release the link.  The
  163.    transport provider may now assume that the link is no longer
  164.    available.
  165.  
  166.    In general, DSLCP maintains and hides the status of link control
  167.  
  168.  
  169.  
  170. Young & Nicholson                                               [Page 3]
  171.  
  172. RFC 1307       Dynamically Switched Link Control Protocol     March 1992
  173.  
  174.  
  175.    transactions from the transport provider.  This way the transport
  176.    provider does not need to keep track of multiple DSLCP transactions.
  177.    For example, if the transport provider requests a link be setup for a
  178.    new transport user while another transport user has the link active,
  179.    the DSLCP may inform the transport provider that the link is ready
  180.    without delay, provided that the link can support multiple transport
  181.    connections.
  182.  
  183. 3.0  FUNCTIONAL SPECIFICATION
  184.  
  185.    This document specifies both a message format and a state machine for
  186.    DSLCP protocol transactions.
  187.  
  188. 3.1  Control Message Format
  189.  
  190.         0                   1                   2                   3
  191.         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  192.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  193.        |  Identifier                   |   Total length                |
  194.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  195.        |  Function                     |   Event Status                |
  196.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  197.        |                Endpoint 1                                     |
  198.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  199.        |                Endpoint 2                                     |
  200.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  201.        |                       Message                                 |
  202.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  203.        |                       Body                                    |
  204.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  205.  
  206.    Identifier: 16 bits
  207.  
  208.        The identifier is a value assigned by the DSLCP used to uniquely
  209.        identify link setup transactions.  It is intended to be used with
  210.        the endpoint addresses by a link controller to identify a
  211.        transaction.
  212.  
  213.    Total length: 16 bits
  214.  
  215.        The total length, in octets, including the header of this DSLCP
  216.        control message.
  217.  
  218.    Function: 16 bits
  219.  
  220.        The operation to be processed or being responded to.
  221.  
  222.        Functions currently defined are:
  223.  
  224.  
  225.  
  226. Young & Nicholson                                               [Page 4]
  227.  
  228. RFC 1307       Dynamically Switched Link Control Protocol     March 1992
  229.  
  230.  
  231.            Bring up        value 0
  232.            Bring down      value 1
  233.  
  234.    Event Status: 16 bits
  235.  
  236.        The state of the controlled link, relative to the last function
  237.        request.
  238.  
  239.        The possible event states are:
  240.            Setup request succeeded        value 2
  241.            Setup request failed           value 3
  242.            Teardown request succeeded     value 4
  243.            Teardown request failed        value 5
  244.            Asynchronous network down      value 7
  245.  
  246.    Endpoint addresses: 32 bits each
  247.  
  248.        The internet addresses of the two communicating parties for which
  249.        the link is being prepared.
  250.  
  251.    Message body:  arbitrary length up to 65499 octets
  252.  
  253.        An ascii string which is meaningful the link controller.  When the
  254.        requesting host is configured, the system administrator sets the
  255.        control strings for each network link that may be accessed by the
  256.        requesting host.
  257.  
  258. 3.2  State Machine
  259.  
  260.    The transport provider is aware of only 2 possible states for the
  261.    controlled link: up or down.  Furthermore, transport users may
  262.    request or release transport services from the transport provider at
  263.    any time.  Thus, there must be a state machine employed by DSLCP when
  264.    communicating between the transport provider and the controlled link.
  265.    This state machine hides the details of link control transactions
  266.    from the transport provider.  The state machine has 6 possible
  267.    states.
  268.  
  269.         Down: There is no active transport connection and the controlled
  270.         link is not setup.
  271.  
  272.         Coming Up: A transport user has requested a connection for which
  273.         the transport provider has given a setup request to the DSLCP.
  274.         The DSLCP has sent a setup request to the link controller and is
  275.         awaiting a response.
  276.  
  277.         Up: At least one transport connection is active and the
  278.         controlled link is setup.
  279.  
  280.  
  281.  
  282. Young & Nicholson                                               [Page 5]
  283.  
  284. RFC 1307       Dynamically Switched Link Control Protocol     March 1992
  285.  
  286.  
  287.         Going Down: All transport connections have been terminated and
  288.         the transport provider has sent an equivalent number of up
  289.         requests and down requests to the DSLCP.  The DSLCP has sent a
  290.         teardown request to the link controller and is awaiting a
  291.         response.
  292.  
  293.         Bring Down: While DSLCP is in the Coming Up state, the transport
  294.         provider requested link teardown.  As soon as a response is
  295.         received from the link controller, the DSLCP will send a
  296.         teardown request if the link setup was successful.
  297.  
  298.         Bring Up: While in the Going Down state, the transport provider
  299.         requested connection setup.  As soon as a response is received
  300.         from the link controller, the DSLCP will send a setup request.
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Young & Nicholson                                               [Page 6]
  339.  
  340. RFC 1307       Dynamically Switched Link Control Protocol     March 1992
  341.  
  342.  
  343.     DSLCP state diagram:
  344.  
  345.               ------- +----------------+
  346.      Transport        |     Down       |<---------\
  347.      Connect     ---->+----------------+           \
  348.      Request    /               ^  ^                \
  349.      -------  Setup             |  |                 \
  350.      Send     Failed            |  |         Teardown \ Response Timeout
  351.      Setup   /------            |  |         Success   \ ---------------
  352.        /    /                   |  |         --------  |
  353.        |    |                   |  |                   |
  354.        |    |                   |  |                   |
  355.        |    | Teardown Response |  |                   |
  356.        |    | Success  Timeout  |  |                   |
  357.        |    | ----------------- |  |     +----------+  |
  358.        |    |      Send---------|--|-----| Bring Up |--|----\
  359.        |    |      Setup        |  |     +----------+  |    | Transport
  360.        |    |     /             |  |               ^   |    | Teardown
  361.        |    |    /              |  |        Transport  |    | Request
  362.        |    |   /               |  |        Connect|   |    | ---------
  363.        |    |  /            Setup  |        Request|   |    |
  364.        |    |  |           Failed  |        -------|   |    |
  365.        v    |  v           ------  |               |   |    v
  366.  +--------------+               |  |              +-------------+
  367.  | Coming Up    |----------+----|--|--Response--->| Going Down  |
  368.  +--------------+          ^    |  |  Timeout     +-------------+
  369.    |    ^      |           |    |  |  --------      ^    ^
  370.    |    |      Transport   |    |  |  Send          |    |
  371.    | Transport Teardown    |    |  |  Teardown      |    |
  372.    |  Connect  Request     |    |  |                /    |
  373.    |  Request  -------     |    |  |               /     |
  374.    |  -------  v           |    |  |              /      /
  375.    |      \ +------------+ -    |  |             /      /
  376.    |       -| Bring Down | ------  |            /      /
  377.     \       +------------+ --------|--Setup-----      /
  378.      \                             |  Success        /
  379.       \                            |  -------       /
  380.        \   Setup           Network |  Send         / Transport
  381.         \  Success         Is Down |  Teardown    /  Teardown
  382.          \ -------         ------- |             /   Request
  383.           \                        |            /    --------
  384.            \                       |           /     Send
  385.             \             +---------------+   /      Teardown
  386.              \----------->|   Up          |---
  387.                           +---------------+
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Young & Nicholson                                               [Page 7]
  395.  
  396. RFC 1307       Dynamically Switched Link Control Protocol     March 1992
  397.  
  398.  
  399. Events and State Transitions
  400.  
  401.    The DSLCP will process three type of events:
  402.  
  403.       A link control request from the transport provider
  404.       An DSLCP message from the link controller
  405.       DSLCP message timeout
  406.  
  407.    The transport provider will make link setup and and teardown requests
  408.    to the DSLCP when transport users request and release services
  409.    requiring link control operations.  The transport provider should not
  410.    keep track of the status of a particular link, as this is a function
  411.    of the DSLCP.  The transport provider may be unaware of redirection
  412.    or other processing of link setup requests performed by DSLCP, so
  413.    this is a function best left to DSLCP.  The DSLCP will inform the
  414.    transport provider as to the success or failure of a particular setup
  415.    request, and transport providers may assume the success of teardown
  416.    requests (the DSLCP will always return a success response to a
  417.    teardown request).
  418.  
  419.    The DSLCP will engage in link control transactions with link
  420.    controllers.  This will include accepting messages from link
  421.    controllers in response to requests as well as unexpected messages
  422.    from the link controller.  Unexpected messages may include redundant
  423.    responses to redundant requests sent as a result of timeouts.
  424.  
  425.    Because of the possibility of unavailable links and link controllers,
  426.    DSLCP should not wait indefinitely for message responses from link
  427.    controllers to which it has sent messages.  Since DSLCP does not
  428.    require the use of a reliable transport protocol to carry DSLCP
  429.    messages, DSLCP must have a timeout and retransmission mechanism.
  430.    Since we have used DSLCP in a local network context with switch
  431.    controllers which offer a quick turnaround (on the order of 1
  432.    second), we use a 5 second timeout with a 3 retransmit limit.  These
  433.    figures would require adaptation to different network and link
  434.    controller configurations, and a self-adapting algorithm would be
  435.    most appropriate for a general solution.
  436.  
  437.    The specific events of interest to the DSLCP are:
  438.  
  439.         Transport provider link setup request
  440.         Transport provider link teardown request
  441.  
  442.         Link setup request failed
  443.         Link setup request succeeded
  444.         Link teardown request succeeded
  445.         Link teardown request failed
  446.         Network link is down
  447.  
  448.  
  449.  
  450. Young & Nicholson                                               [Page 8]
  451.  
  452. RFC 1307       Dynamically Switched Link Control Protocol     March 1992
  453.  
  454.  
  455.         Timeout waiting for DSLCP response from link controller
  456.  
  457.    The necessary processing for each event while in each state is as
  458.    follows:
  459.  
  460.         Transport provider link setup request
  461.  
  462.             Down:
  463.                 Send setup request to link controller.
  464.                 Enter Coming Up state.
  465.                 Notify transport provider to wait until link is up.
  466.  
  467.             Coming Up:
  468.             Bring Up:
  469.                 Notify transport provider to wait until link is up.
  470.  
  471.             Up:
  472.                 Notify transport provider that link is up.
  473.  
  474.             Bring Down:
  475.                 Enter Coming Up state.
  476.                 Notify transport provider to wait until link is up.
  477.  
  478.             Going Down:
  479.                 Enter Bring Up state.
  480.                 Notify transport provider to wait until link is up.
  481.  
  482.             Discussion:
  483.  
  484.             If the controlled link is not capable to support multiple
  485.             transport connections, then the DSLCP must return
  486.             appropriate errors when it detects multiple transport setup
  487.             requests for that link.
  488.  
  489.         Transport provider link teardown request.
  490.  
  491.             Down:
  492.             Bring Down:
  493.             Going Down:
  494.                 Notify transport provider that link is down.
  495.  
  496.             Coming Up:
  497.                 Enter Bring Down state.
  498.                 Notify transport provider that link is down.
  499.  
  500.             Bring Down:
  501.                 Notify transport provider that link is down.
  502.  
  503.  
  504.  
  505.  
  506. Young & Nicholson                                               [Page 9]
  507.  
  508. RFC 1307       Dynamically Switched Link Control Protocol     March 1992
  509.  
  510.  
  511.             Up:
  512.                 Send teardown request.
  513.                 Enter Going Down state.
  514.                 Notify transport provider that link is down.
  515.  
  516.         Link setup request failed
  517.  
  518.             Down:
  519.             Going Down:
  520.             Bring Up:
  521.                 Unexpected message, possibly due to duplicate requests -
  522.                 ignore it.
  523.  
  524.             Up:
  525.                 Unexpected message, link controller may be refusing
  526.                 multiple setup requests sent because of timeout - ignore
  527.                 it.
  528.  
  529.             Coming Up:
  530.             Bring Down:
  531.                 Enter down state.
  532.  
  533.         Link setup request succeeded
  534.  
  535.             Down:
  536.                 Unexpected message, possibly due to duplicate requests
  537.                 and reordering of request packets by network.
  538.                 Send teardown request.
  539.  
  540.             Going Down:
  541.             Bring Up:
  542.             Up:
  543.                 Unexpected message, possibly due to duplicate requests -
  544.                 ignore it.
  545.  
  546.             Coming Up:
  547.                 Enter Up state.
  548.                 Notify transport provider(s) waiting for link that it is
  549.                 available.
  550.  
  551.             Bring Down:
  552.                 Send teardown request.
  553.                 Enter Going Down state.
  554.  
  555.         Link teardown request succeeded
  556.  
  557.             Down:
  558.             Coming Up:
  559.  
  560.  
  561.  
  562. Young & Nicholson                                              [Page 10]
  563.  
  564. RFC 1307       Dynamically Switched Link Control Protocol     March 1992
  565.  
  566.  
  567.             Bring Down:
  568.                 Unexpected message, possibly due to duplicate requests -
  569.                 ignore it.
  570.  
  571.             Up:
  572.                 Unexpected message, possibly due to duplicate requests
  573.                 and reordering of request packets by network.
  574.                 Send teardown request.
  575.                 Enter Going Down state.
  576.                 Notify transport providers that link has gone down.
  577.  
  578.             Bring Up:
  579.                 Send setup request
  580.                 Enter Coming Up state
  581.  
  582.             Going Down:
  583.                 Enter Down state
  584.  
  585.             Discussion:
  586.  
  587.             If a teardown request succeeded message arrives when the
  588.             DSLCP is in the UP state, then some error has occurred, and
  589.             the conservative approach is to bring down the connection
  590.             and resynchronize.  However, it may be satisfactory to
  591.             ignore the message without ill effect.
  592.  
  593.  
  594.         Link teardown request failed
  595.  
  596.             Down:
  597.             Coming up:
  598.             Bring Down:
  599.             Bring Up:
  600.             Going Down:
  601.             Up:
  602.                 DSLCP sent a teardown request message for an invalid
  603.                 transaction.  The link controller has no
  604.                 identifier/endpoints transaction record for the request.
  605.                 Continue as if request had succeeded.
  606.  
  607.         Network link is down
  608.  
  609.             Down:
  610.                 Ignore message.
  611.  
  612.             Bring Down:
  613.             Going Down:
  614.                 Enter Down state.
  615.  
  616.  
  617.  
  618. Young & Nicholson                                              [Page 11]
  619.  
  620. RFC 1307       Dynamically Switched Link Control Protocol     March 1992
  621.  
  622.  
  623.             Coming up:
  624.             Bring Up:
  625.             Up:
  626.                 Enter down state.
  627.                 Notify transport provider that link is down.
  628.  
  629.  
  630.         Timeout waiting for DSLCP response from controller
  631.  
  632.             Down:
  633.             Up:
  634.                 DSLCP protocol error - fix bug, don't set timer when
  635.                 there are no outstanding requests.
  636.  
  637.             Coming Up:
  638.             Bring Down:
  639.                 Send teardown request.
  640.                 Enter Going down state.
  641.  
  642.             Going Down:
  643.                 Enter Down state.
  644.  
  645.             Bring Up:
  646.                 Send setup request.
  647.                 Enter Coming Up state.
  648.  
  649. References
  650.  
  651.    [1]  Nicholson, et. al., "High Speed Networking at Cray Research",
  652.         Computer Communications Review, January, 1991.
  653.  
  654.    [2]  Nicholson, A., and J. Young, "Experiences Supporting By-Request
  655.         Circuit-Switched T3 Networks", RFC 1306, Cray Research, Inc.,
  656.         March 1992.
  657.  
  658. Security Considerations
  659.  
  660.    Security issues are not discussed in this memo.
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Young & Nicholson                                              [Page 12]
  675.  
  676. RFC 1307       Dynamically Switched Link Control Protocol     March 1992
  677.  
  678.  
  679. Authors' Addresses
  680.  
  681.    Jeff Young
  682.    Cray Research, Inc.
  683.    655F Lone Oak Drive
  684.    Eagan, MN 55123
  685.  
  686.    Phone: (612) 452-6650
  687.    EMail: jsy@cray.com
  688.  
  689.  
  690.    Andy Nicholson
  691.    Cray Research, Inc.
  692.    655F Lone Oak Drive
  693.    Eagan, MN 55123
  694.  
  695.    Phone: (612) 452-6650
  696.    EMail: droid@cray.com
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Young & Nicholson                                              [Page 13]
  731.